Hi, thanks for noting this problem and opening this PR.

I do see some issues with the approach that you have chosen to fix this, though. First, given that multiple selectors can be combined, baseJson can be inverted multiple times, resulting in incorrect behaviour. Second, when for example a driver selector is combined with the laps endpoint, the endpoint still needs to be included. This is not the case with your solution.

I suggest instead that the drivers endpoint is implemented similarly to, for example, the laps endpoint. In fact, the drivers, constructors, circuits and status endpoint need to be implemented in this way. Do you want to update your PR? Please also adhere to the PEP8 style guidelines.

I've updated the commit on this. I see what you're suggesting this behavior is already in place for a few endpoints, such as lap. I mimicked the behavior over into the recommended endpoints you provided. This allowed us to completely remove baseJson

After reinvestigating the failure it seems that there is some complexity to wrap my head around.

• The order of the selectors is meaningful
• The endpoint value is specific to a call e.g get_circuit_info()
• With certain endpoints the postfix is necessary e.g "circuits"
• With certain combinations the postfix is not necessary e.g season & round

Theoretically I need to further mimic the laps

Yes, exactly. The API endpoint structure is not very consistent.

Noting saw docs with amend future commits
(Summary for PR Authors)

Is this a breaking change, considering the changes alter the data from ergast?

I've altered the calls to replicate the function you shared.
There is one addition for conditional implemented for get_race_schedule.
These are two examples from ergast, you can notice one has the races endpoint while the others omit it.

https://ergast.com/api/f1/2012
https://ergast.com/api/f1/2008/5
https://ergast.com/api/f1/drivers/alonso/circuits/monza/races

Don't think I got this part perfected. I need to use something alternative besides selector length.
As you can see in the second example call there is a value for round, this will currently trigger the appending of /races

Is this a breaking change, considering the changes alter the data from ergast?

No, the current behaviour is incorrect, therefore this is a bug fix.

I'll have a look at everything and do some manual testing, and then I'll get back to you.

I pushed some minor changes to your branch and added more tests. Everything looks good now. Thank you for noticing this issue and for helping to fix it.